A memory leak refers to an allocated memory region, a memory block, for example, which, after being used by a program running on a computer, is not released. For the entire run time of the program, this memory region, in particular memory block, can then no longer be used for the program or for other purposes (other programs or operating system requirements), so that the free memory still available may run low, particularly when such memory leaks occur numerous times.
In addition, as the result of fragmentation of the main memory due to unreleased memory regions it may no longer be possible for the system to effectively access large contiguous memory blocks (larger than 100 MB, for example). The system may be burdened and may become progressively more unstable.
For programmers, such memory management errors occur relatively frequently in computer-based languages (such as C/C++). Due to the ever-increasing complexity, the programmer forgets to release the reserved memory region/memory block at the correct time. A detailed discussion of the fundamentals of memory leaks is disclosed in US 2005/0235127 A1 and US 2004/0078540 A1, for example.
By use of automated software it is practically impossible to determine the point in time after which a memory region/memory block is no longer being used by a program. There is currently no tool which allows the developer to identify 100% of such cases. Although the developer can obtain a list of all memory leaks that have occurred after the program has ended, as described below, in order to eliminate the underlying programming error the developer would require an association with the specific situation during the program execution in which the memory region/memory block in question is allocated.
Commercially available tools, such as the FindLeak program by cjt Systemsoftware AG and the methods described in US 2005/0235127 A1 and US 2004/0078540 A1, give the developer a heuristic method-based indication of potential memory leaks. A disadvantage is that the developer must constantly verify the individual memory leaks; i.e., it is not clear that all unreleased memory region/memory blocks are memory leaks until the program has ended. No option is provided for associating the confirmed memory leaks at the end of the program with the heuristic information, and thus there is no option for tracking more detailed information about the memory leak when the program is running.
To reduce the described problems, with CRT (C run-time) library and MFC (Microsoft Foundation Classes) Microsoft Visual Studio offers the developer the option of labeling potential memory leaks after a program has run. To this end, MFC logs all memory allocations and deallocations, and after the program has run, indicates all remaining entries as text output, for example, in a debug output window in the form of a memory leak list or memory leak dump. Thus, by use of this option offered by Microsoft or other providers the programmer may generate a memory leak list in which all memory regions/memory blocks that are allocated but no longer released are listed, optionally together with other information.
An MFC application generated in Visual Studio using wizard support automatically logs and reports the memory requirements. In self-generated configurations, the developer may start the log process using the _CrtSetDbgFlag method.
The information which MFC is able to provide at this point in time is rudimentary. Class names or call stacks are no longer available after the program has ended, and logging of this information during the run time is very memory-intensive. The file name and the line number in which the object is allocated is sometimes given, but frequently this information is not provided, since the name of the file from which the request comes is not known unless the name has been specifically delivered to the logging memory management routines, which often does not occur. Preprocessor macros are used for this purpose, but such macros are prone to malfunction, if they can be used at all. Thus, as a rule only about 50% of memory leaks are provided with file names.
Although the file name and line number give a precise indication of the object that has been allocated, in most cases this is not useful to the developer, since the allocation code is generally satisfactory and the programmer must determine why the object is being allocated and not released, and in particular, at what location in a program this error has occurred.
The memory address contains little useful information since it changes with each program run, and after the program has run the memory address provides no information concerning the context of the allocation.
Under special circumstances the memory block size gives the developer information about the object, but generally is not predictive and therefore is not used in standard methods. In addition, the experience of the developer is a factor that determines the usefulness of this information.
The core concept of a method proposed by Microsoft for eliminating memory leaks is the introduction of a consecutive allocation number which indicates the order number of the memory allocation during the program run which has resulted in the memory leak.
Together with the referenced logging option, there is, for example, the function (_CrtSetBreakAlloc) by means of which the developer may interrupt execution of the program when an allocation number delivered to the function has been reached. If the developer provides the number reported at the last memory leak dump to said function, the program pauses at the next run exactly at the location where the “lost” object is allocated. This association of the identified memory leak with the specific run time situation during the allocation gives the developer crucial information for eliminating the underlying programming error.
For large GUI-intensive applications, however, in actual practice allocation numbers are in the 6 to 8 digit range for most memory leaks. Due to the intense networking of these applications with the autonomous GUI and task management of the operating system, the linkage between the object allocation and the allocation number is no longer deterministic. Even small differences in run time between two program runs intended to be identical result in unpredictable shifts in the allocation numbers for the same object in the various runs.
This may be due to the fact that, for example, in addition to the allocations of memory regions by the program to be investigated, the operating system or other programs running in parallel also perform allocations of memory regions. This results in intermingling of the memory allocations and possibly of the releases of the program that is to be investigated with the allocations and possibly releases of other programs or the operating system. This makes it virtually impossible for a programmer to draw conclusions concerning the reason for an allocation, and in particular, the lack of a deallocation.
The method proposed by Microsoft reaches its natural limit at this point. Because of the difficulty in determining the circumstances of allocation and release, the allocation number loses its informative value, and it is therefore impossible to search for the underlying programming error for the memory leak.